For now, we only have `SubTypeTest` and `LegacyPatMat`.

* `SubTypeTest` is used when there is no type capture.
* `LegacyPatMat` is used when there are captures.

In the match type reduction algorithm, we already have a simpler
path for `SubTypeTest`.

The `LegacyPatMat` path is basically the same as before, but with
static knowledge that we have an `HKTypeLambda`.

This is the first step in using the new specified algorithm for
match type reduction. When the pattern of a case satisfies
elibility conditions, we use the new algorithm. Otherwise, we fall
back on the legacy algorithm.

To be eligible, a pattern with at least one capture must be:
an applied *class* type constructor whose arguments are all:
- either a type capture,
- or a fully defined type that contains no inner capture,
- or the argument must be in covariant position and recursively
  qualify to the elibility conditions.

With those criteria, all the type captures can be *computed* using
`baseType`, instead of inferred through the full `TypeComparer`
machinery.

The new algorithm directly handles preventing widening abstract
types, when doing so leads to captures being under-defined. With
the legacy algorithm, this prevention is scattered elsewhere in
the type comparer. Making it centralized improves the error
messages in those situations; it seems they were previously
entirely misleading (see changed check files).

So that they do not fall into the legacy fallback.

An abstract tycon can be matched if it is exactly equal to the
scrutinee's tycon.

The error can be silenced with `-source:3.3`. In that case,
illegal match types are reduced using the legacy matching
algorithm, as before.

Previously the disjointnessBoundary of HKTypeLambda's was
implicitly their `resultType`, through the use of
`superTypeNormalized`. This was fine as long as both sides of
`provablyDisjoint` ended up being HKTypeLambda's at the same time,
but this may not always be the case (notably with any-kinded types).

It is safer to consider type lambdas as boundaries themselves, and
explicitly recurse on the result types when arities match.

This change surfaced a weird case in `TypeTestsCasts`, which called
`provablyDisjoint` with ill-kinded types. We now explicitly apply
what I suspect are partially-erased types to wildcards to recover
appropriate kinds.

… instead.

Fundamentally, the `provablyEmpty(scrut)` test was meant to prevent
situations where both `scrut <: pattern` and
`provablyDisjoint(scrut, pattern)` are true. That is a problem
because it allows a match type to reduce in two different ways
depending on the context.

Instead, we basically use that combination of `scrut <: pattern`
and `provablydisjoint(scrut, pattern)` as the *definition* for
`provablyEmpty`. When both those conditions arise together, we
refuse to reduce the match type.

This allows one example to pass that did not pass before, but that
particular example does not seem to cause unsoundness. In a sense,
`provablyEmpty` was too strong here.

Closes scala#17121.
Closes scala#17944.
Closes scala#18488.

This should improve consistency with the actual earlier compilers,
since it means the matching algorithm will be intact.

Note that the new behavior of `provablyDisjoint` is always applied,
even under `-source:3.3`. This includes using `provablyDisjoint`
instead of `provablyEmpty`. So it is still possible that something
behaves differently than the actual earlier compilers.

This was already done for `TypeApply` in
cecfb61. We apply the same logic
for `Apply` nodes.

And add an additional test for another cause of infinite recursion
that was fixed earlier.

This additional test demonstrates that relaxing the `isConcrete`
in a particular way around `AndType`s would also cause unsoundness.

This justifies new failures in the Open Community Build.